home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 13085 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.3 KB
  1. Path: ix.netcom.com!netnews
  2. From: pcgpe@ix.netcom.com(Mark Feldman)
  3. Newsgroups: comp.lang.c++
  4. Subject: Inheritance problem...and other stuff
  5. Date: 23 Mar 1996 09:01:07 GMT
  6. Organization: Netcom
  7. Message-ID: <4j0ekj$9f6@cloner3.netcom.com>
  8. NNTP-Posting-Host: chi-il10-16.ix.netcom.com
  9. X-NETCOM-Date: Sat Mar 23  1:01:07 AM PST 1996
  10.  
  11.  
  12. Heya,
  13.  
  14. I remember seeing a C++ FAQ once but I haven't had any luck finding it
  15. again. If someone could point me to it I'd be grateful.
  16.  
  17. In the mean time I'll go ahead and ask my questions...at the risk of
  18. asking something in the FAQ and getting flamed for it :) 
  19.  
  20. Here's a generic form of my problem. (BTW I use BC 3.1 and MSVC 4.0 and
  21. solutions for either compiler would be fine.) Let's say I have a tree
  22. of objects like this:
  23.  
  24.               food
  25.            /         \
  26.           /           \
  27.       fruit           vegetable
  28.    /    |    \         /    \
  29. apple orange banana  pea   potato
  30.  
  31.  
  32. Now I maintain an array of pointers to objects, each of which points to
  33. some type of object in the tree:
  34.  
  35. foodptr array[ARRAYSIZE];
  36.  
  37. I've given food two virtual functions, char * name() which is used for
  38. identification purposes and BOOL isA(name) which I want to use to get
  39. information about an object. At the moment each object overrides both
  40. functions.
  41.  
  42. To print each object's name I simply loop through the array and call
  43. array[]->name();
  44.  
  45. What I want to do however is determine info about the object which is
  46. inherited from it's parents. Thus if my object is of type apple then
  47. calling apple->isA("apple") should return true. apple->isA("fruit")
  48. should also return true, but apple->isA("vegetable") should return
  49. false. If for example I have many different types of apples I want to
  50. be able to call any object with object->isA("apple") and find out if
  51. it's at least a type of apple. The overload for apple::isA() would
  52. therefore look something like this:
  53.  
  54. BOOL apple::isA(char * type)
  55. {
  56.  return (!stricmp(name, type)) || fruit::isA(type);
  57. }
  58.  
  59. Now the easiest solution would be to simply overload isA for every type
  60. of class, but my question is if there is any way to avoid this?
  61. Something like this would make life a bit easier for me:
  62.  
  63. BOOL fruit::isA(char * type)
  64. {
  65.  return (!stricmp(name, type)) || Parent::isA(name);
  66. }
  67.  
  68. where apple, orange, banana and any of their child classes
  69. automatically inherit this function and call the appropriate parent. Is
  70. it possible or even advisable to do something like this?
  71.  
  72. 2nd Question:
  73.  
  74. What's the standard way of storing such an array to a file and
  75. retrieving it? I could always assign an ID number to each class type
  76. and load them using case statements but this seems messy. I notice that
  77. MFC and OWL seem to use tables to handle the dispatching of windows
  78. messages. Would it be feasable to use this for saving the array info to
  79. a file? Idealy I would like each function to inherit a serialization
  80. function which they can overload to save and restore their data, but
  81. how can I make the loading routine know what type of class to create in
  82. the first place while still keeping the code tight and clean?
  83.  
  84. Am I going about all this the wrong way? For some time now I've
  85. considered myself a "good" C++ programmer. When I hit problems like
  86. this I start to wonder if I'm really nothing more than a C programmer
  87. with a C++ compiler. Feels like playing Zork on a Pentium.
  88.  
  89. All help/suggestions/flames etc appreciated.
  90.  
  91. Cheers,
  92.  
  93. Mark Feldman
  94.  
  95.